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Simulink/Stateflow charts are widely used in industry for the specification of control systems, which 
are often safety-critical. This suggests a need for a formal treatment of such models. In previous 
work, we have proposed a technique for automatic generation of formal models of Stateflow blocks 
to support refinement-based reasoning. In this article, we present a refinement strategy that supports 
the verification of automatically generated sequential C implementations of Stateflow charts. In 
particular, we discuss how this strategy can be specialised to take advantage of architectural features 
in order to allow a higher level of automation. 

1 Introduction 

MATLAB Simulink ll24l is a graphical notation widely used in the automotive and avionics indus- 
tries; it supports the specification of control systems in a level of abstraction convenient for engineers. 
A Simulink diagram consists of blocks and wires connecting the inputs and outputs of the blocks. 

Stateflow [25 ] is an extension of Simulink that supports the specification of state transition systems, 
providing a new Simulink block, namely, a Stateflow chart. It is a variant of Statecharts lfT2l . which 
extends standard state-transition systems by introducing new features, such as hierarchy and parallelism. 

While Simulink diagrams are typically used to specify aspects of a system that can be modelled 
by differential equations relating inputs and outputs, Stateflow charts usually model the control aspects. 
There is a wide range of tools that support Simulink and Stateflow. These include a simulation and 
analysis tool, a verification and validation tool, a code generator and a prototyping tool |[24l 1251 |23) . 

The extensive use of Simulink/Stateflow in the development of safety-critical systems, associated 
with certification standards [3,9] that recommend the use of formal methods for the specification, design, 
development and verification of software, makes a formal treatment of these notations extremely useful. 

We are concerned with the assessment of the correctness of implementations of Stateflow charts. A 
frequent approach to this problem is based on the verification of automatic code generators ll4l l27llT3l . 
We propose an orthogonal approach based on the verification of implementations with respect to a model 
of the chart. An overview of our approach is given in Figure [T] 

This approach consists of deriving formal models of a Stateflow chart and its implementation, and 
applying the refinement calculus to check the correctness of the model of the implementation with respect 
to the model of the chart. This is particularly suited for situations where automatically generated code is 
not applicable or convenient, for instance, in situations where hardware and performance requirements 
require changes in the generated code. Moreover, Simulink and Stateflow are frequently updated, and 
these updates can have a heavy impact on the cost of the verification of any code generator. 

In |[T6ll . we propose an operational model of Stateflow charts, provide translation rules for deriving 
such models, and discuss a tool that automatically generates the model of a Stateflow chart. The model of 
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Figure 1: An approach for the verification of implementations of Stateflow charts. 

a Stateflow chart is formed by the composition of two processes: the first models the general semantics of 
Stateflow [25 ], and the second models specific aspects of a chart. The model of the semantics of Stateflow 
chart is structured in a way that facilitates the inspection and comparison to the informal semantics found 
in ll25ll . as no formal analysis can be made because the semantics of Stateflow is available in an informal 
way [25 ] or is hidden in the simulation tool. 

The refinement calculus is enough for the purpose of verifying such models. However, the expertise 
required for such verification is often not available. Moreover, the complexity of Stateflow and the size 
of real charts potentially renders the manual application of the refinement calculus infeasible. We aim 
in our approach to hide as much of the formalism as possible, to allow it to be used in real scenarios by 
engineers and programmers. For that to be achieved, we must provide means for the refinement to be 
established at least in a semi-automatic way. 

We propose a verification strategy for sequential automatically generated implementations of discrete- 
time Stateflow charts with respect to models of Stateflow constructed (automatically) as described in |[T6ll . 
This technique is closely related to that proposed in @ for verification of implementations of Simulink 
diagrams. Our work extends those results to cover a larger class of diagrams and implementations. 

The implementations that we consider are those that follow the architectural pattern employed by the 
code generator provided by MATLAB. There are other code generators |[22ll27l . but as far as we know, 
they all cover a limited subset of the Stateflow notation. Fixing the architecture of the implementation 
allows us to specialise the details of the strategy to increase its level of automation. 

Our models for Stateflow charts are specified in Circus 11291 , a formal notation that integrates Z 11301 , 
CSP [21], Dijkstra's language of guarded commands [8], and the refinement calculus ifTTl . These mod- 
els are particularly adequate for refinement-based verification techniques. Our technique uses the Circus 
refinement laws to provide a tactic of refinement that can be used to prove the correctness of an imple- 
mentation in a highly automated way. Soundness of the technique stems from soundness of the laws. 

This article is structured as follows. Section [2] introduces the background material necessary for 
the presentation of our strategy. Section [3] discusses the architecture of automatically generated im- 
plementations of Stateflow charts and provides general guidelines for deriving Circus models of these 
implementations. Section [4] describes our refinement strategy for the verification of implementations of 
Stateflow charts. Section [5] assesses our contributions, examines related work, and discusses directions 
for future developments. 



2 Background material 

In this section, we introduce the Stateflow and Circus notations, and our formal models of Stateflow charts. 
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Figure 2: Absolute value chart. 

2.1 Stateflow charts 

Figure [2] shows our running example: a Stateflow chart adapted from an example supplied with the tool. 
The chart has one input variable (u) and one output variable (y); it outputs in y the absolute value of u. 

A Stateflow chart is built from a series of components, such as states, transitions, junctions, data and 
events. States are represented by rectangles with round corners; in our example, the boxes marked with 
P and N are states. States, as well as charts, can have substates, which are arranged in a sequential or 
parallel decomposition. A state with a sequential decomposition has at most one substate active at any 
given time, while a state with a parallel decomposition has all of its substates active or inactive at once. 

A state has a set of actions associated with it, namely, entry, during, exit, on, and binding actions. 
Entry, during and exit actions are executed when the state is entered, executed, and exited, respectively; 
on actions are executed in the same situations as during actions, with the additional requirement that a 
particular event is being processed; and binding actions bind a particular event or data to the state. In our 
example, both P and N have a during action. In P, u is assigned to y, and in N, -u is assigned to y. 

Two states (within a state or chart with sequential decomposition) can be connected by one or more 
transitions; they are indicated by arrows and can be guarded by events and conditions. There are two 
types of actions associated with a transition: condition and transition actions. Condition actions are 
executed when the guard of the transition (event and condition) is true, and transition actions are executed 
when the transition leads to a state being exited. 

Transitions are classified according to the relative position between its source and target states; inner 
transitions have the target state as a substate of the source state, and outer transitions do not. There is a 
special type of transition, called default transition, that has no source; it is used to indicate the default 
path to be taken when a state or chart is first entered. In our example, we have one default transition, and 
five outer transitions. Three of the transitions are guarded by a condition: u>=0, u<0, or u>=0. 

A transition path is formed by a series of transitions linked by junctions which are represented by 
circles. There are two junctions in our example; they form two transition paths. A transition path is 
completed only when a state is reached by following all the transitions in the path. When a transition 
path is completed, the source of the path is exited, the transition actions of the path are executed, and 
the target state is entered. Additionally, there is a special type of junction, called history junction, which 
records the most recently activated substate of the state that contains it. 

In the example in Figure [2j initially, the chart is inactive; the first time it is executed, it is activated 
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channel in ,inl, in2 ,out : seq N 
process Merger = begin 
stated ==[y: seqN] 
InitS== [S'\y' = {}} 
Merge = xl,x2 : seqN • 

/ if#jcl =0 — >y :=y^x2 
O#x2 = — >y:=y^xl 
\\#x\ ^0 A#x2/0 — ► 
^ if headxl < headx2 — 
\\headxl > headx2 — i 

V fl 
V fi 

• InitS ; inllxl 

end 

process SplitSorter = 



\ 



>j :=y^ (headxl) ; Merge (tail xl,x2) 
■y :=y^ (headx2) ; Merge(xl,tailx2) 



•z'n2?x2 — ^Aferge(xl,x2) ; ow/!)> — ^Skip 



process Parallel 'So rte r — j |{| in 1 . in2 \\'\ | \ {] inl,in2 1} 
Figure 3: The ParallelSort specification. 



SplitSorter 

Uin\,in2U 
Merger 



and one of its two states is entered depending on whether u is greater than or equal to zero (state P) or 
not (state N). In the next execution, if the sign of u has changed, a transition takes place from one state to 
the other. If there is no change, the during action of the active state assigns the absolute value of u to y. 
Before presenting the Circus model of this chart, we give, in the next section, an overview of Circus. 



2.2 Circus 

We present the main Circus features using the example in Figure [3] It models a parallel sorter that reads 
a sequence of natural numbers through the channel in, and writes on the channel out an ordered version 
of the input sequence. A detailed presentation of Circus can be found in (29J. 

A Circus specification is a sequence of paragraphs: Z paragraphs (axiomatic definitions, schemas, 
and so on), channel and channel set declarations, and process definitions. The first paragraph of our 
example defines four channels in, inl, in2, and out, which communicate sequences of natural numbers, 
that is, elements of the type seqN. The second paragraph is a basic process definition. It provides the 
name of the process {Merger), the definition of its state using a schema S, an action InitS defined by an 
operation schema, an action Merge, and a main action (after a •), which defines, using the previously 
defined actions, the overall behaviour of the process. 

In general, Circus actions are written using a mixture of Z and CSP constructs, and guarded com- 
mands. In our example, the main action initialises the state using InitS, reads a value xl through the 
channel inl, reads a value x2 through in2, calls Merge with the values xl and x2 as parameters, and 
outputs the state variable y through out. 

The schema S has only one component y of type seqN, that is, the set of sequences of natural num- 
bers. The schema InitS specifies an initialisation operation over 5 that sets y to the empty sequence (()). 
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Like in Z, we use / to refer to the value of y after the operation. 

The action Merge takes two sequences xl and x2 of natural numbers, and appends them to the state 
variable y, so that if both input sequences are ordered, the final sequence in y is also ordered. The 
specification of Merge uses a conditional and assignments from the guarded commands language. If one 
of the sequences is empty, the non-empty sequence is appended. When both sequences are not empty, 
Merge compares the first element of each sequence (headxl < headxl), appending the smallest of them 
to y, and recursively calls Merge on the rest of the sequence that had the smallest element (tailxl or 
tailxl), and the whole of the other sequence. 

Processes encapsulate their state and interact with other processes through channels. The usual 
CSP operators can be used to combine processes. The fourth paragraph in Figure [3] defines the pro- 
cess ParallelSorter as the parallel composition of the processes SplitSorter and Merge, communicating 
over the channels inl,in2. The process SplitSorter in the third paragraph is omitted; it splits a sequence 
of natural numbers in two, sorts each sequence in parallel, and outputs them through channels inl and 
in2. In the definition of ParallelSorter, the channels inl and inl are hidden, thus yielding a process 
whose interface contains only the channels in and out. 

In the next section, we have another example of a process; the model of the chart in Figure|2] 

2.3 A formal model of Stateflow charts 

In this section, we describe the Circus operational models of Stateflow charts that we can generate au- 
tomatically. In these models, the execution of one step of the chart is initiated by reading inputs, and 
concluded by writing outputs, and synchronising on a channel called end_cycle. A more detailed de- 
scription can be found in Il5lll6l . 

Our models consist of two Circus processes in parallel. The first, Simulator, represents the simulator, 
and is the same for every chart. The second, the chart process, represents a particular chart. The simulator 
and the chart processes communicate over the channels in the set interface plus the channel end_cycle, 
with the channels in interface hidden. Figure |4] shows the structure of the automatically generated model 
of the chart in Figure [2] 

The chart process P _AhsoluteValue uses a data model that defines the state, transition, and junction 
identifiers, as well as the states, transitions, and junctions as bindings of specific schemas. These are 
constants that capture information about the structure of the chart. They are represented by the first 
rectangle in Figure |4| These constants are collected in four other constants defined within the chart 
process: identifier, states, transitions, and junctions. The constant identifier records the identifier of the 
chart and states, transitions, and junctions are partial functions that map identifiers to the corresponding 
binding. These constants are declared using a schema Statefow Chart whose definition is omitted in 
Figure [4] Their values are fixed in the process chart. 

Next, the chart process defines a series of schemas that specify components of the state and cor- 
responding initialisation operations. Information about which states are active and which states are 
recorded in the history junctions is recorded in the schema SimulationData, and chart variables are 
recorded in the schema Simulationlnstance. These schemas are conjoined to define the schema State that 
specifies the state of the process. We adopt the convention of prefixing a v_ to the name of the chart 
variable to clarify the nature of the name. 

Next, the chart process defines a series of Circus actions that can be divided into four groups: actions 
that correspond to state and transition actions, actions that correspond to calculation of triggers and 
conditions, actions that read inputs and write outputs, and actions that output the structure of the chart. 
All these actions are grouped to define AUActions, which is used in the main action as shown in Figure [5] 
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Constant definitions: identifiers and bindings 



process P_AbsoluteValue 
Constants: Diagram Structure 

State: status of chart states 

Actions 1 : state and transition actions 

Actions 2: triggers and conditions 

Actions 3: chart inputs and outputs 

Actions 4: output of the structure of the chart 

AIIActions: external choice of the actions above 



Main action: recursive offering of all actions 



process Simulator 



Execute transitions actions 
Enter state actions 



Execute state actions 



Exit state actions 



Execute chart actions 



Local event execution actions 
Step of execution action 



Main action: recursive execution of the step 



process AbsoluteValue ^ (P_AbsoluteValue \\ Simulator)\interface 



Figure 4: Structure of the model of the chart in Figure [2] 



(/ / ((AIIActions A (interrupt _chart — s-Skip));F) 

llY • □ 
\ \ end_cycle — )>Skip 

end 

Figure 5: Main action of the chart process shown in Figure [4] 



; X 



The main action of the chart process is shown in Figure[5J it initialises the state, and recursively offers 
the actions in AIIActions, with the additional possibility that any of these actions can be interrupted at 
any time by a communication over the channel interrupt _chart. The possibility of interruption accounts 
for the occurrence of early return logic in the chart, that is, the interruption of the execution of the 
chart brought about by a state inconsistency produced by a local event broadcast. The main action has 
two nested recursions: the internal one corresponds to the actions that are offered to one particular step 
of simulation, and can be terminated by a synchronisation over the channel end_cycle. The external 
recursion corresponds to the recursive execution of simulation steps. 

The process Simulator does not have a state; it declares a series of actions that model the execution 
of transitions, as well as the processes of entering, executing and exiting states. The execution of a chart 
is then defined in terms of the previous actions. A chart can be executed multiple times in the same time 
step due to the occurrence of multiple input events or the broadcast of a local event. In the first case, 
an action encodes the execution of the chart for each active event in the appropriate order and is used 
to define the step of execution. In the second case, we define an action that captures the occurrence of 
a broadcast and executes the chart under the appropriate setting. This action is called whenever a state 
or transition action is executed. All these actions are combined to define the step of execution of the 
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Figure 6: Architcture of the implementations of Stateflow charts 



simulator, which is called recursively in the main action of the process Simulator. 
In the next section we discuss an approach to modelling implementations of charts. 



3 Implementations of Stateflow charts 

Figure [6] shows the structure of implementations of Stateflow charts generated automatically by Real 
Time Workshop/Stateflow Coder. In general, the implementations produced consist of a series of struc- 
tures that define the state of the chart (inputs, outputs, local variables, events, execution state, and so on) 
and a series of procedures. The procedures can be divided into those that implement the execution of 
the chart, which are relevant for our verification, and those that calculate the next time step. Since we 
capture time using synchronisation, we restrict our attention those of the first kind depicted in Figure [6] 
as calculate_outputs, initialization and calculate_step. 

The procedure calculate_outputs implements the execution of the chart, initialization ini- 
tialises the variables of the program, and calculate_step implements the control of the execution of 
the chart according to the number of active events. The main procedure of the implementation initializes 
the program and repeatedly calculate the outputs using the procedure calculate_step. In the case of 
a C implementation, the procedures shown in Figure [6] are implemented as C functions whose names re- 
flect the name of the chart. In our example, for instance, the procedure calculate _outputs is implemented 
as the C function AbsoluteValue_output. 

Of particular interest to us is how the implementation models information regarding the status of the 
states. This is done in two different ways, according to the type of decomposition of the states. In this 
discussion, we regard the chart as a state. If the state has a parallel decomposition, its status is modelled 
by a single variable in the structure D_Work_K, where X is the name of the chart. This variable is called 
is-activeS, where S is the name of the state; it has a numerical type (uint8_T), but, in fact, it is used as 
a boolean variable, that is, if its value is zero the state is not active, otherwise, it is active. 
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DJWork^AbsoluteValue == [is^active-c\^AbsoluteValue,is_c\^AbsoluteValue : N] 
process AbsoluteValue = begin 

state AbsoluteValue state == [AbsoluteValue_DWork : D_Work_AbsoluteValue; . . .] 
AbsoluteValue JDWorkAs-c\^AbsoluteValue = x : N • AbsoluteValue JDWork := 

\is -active _c\ ^AbsoluteValue == AbsoluteValue_DWork.is_active_c\-AbsoluteValue, 

is_c\-AbsoluteValue == _y[) 

AbsoluteValue— output = tid : 7L • 
^ / iSAbsoluteValue_DWork.is_active_c\_AbsoluteValue = — > \ 
AbsoluteValue— DWork_is^active-cl-AbsoluteValue(l ) ; 
/ if AbsoluteValue JB .SineWavel > — >• \ 
AbsoluteValue_DWork_is_cl-AbsoluteValue(AbsoluteValue_IN_P) 
[]-■ (AbsoluteValue^ .SineWavel > 0) )• 

AbsoluteValue_DWork_is_cl_AbsoluteValue(AbsoluteValue_IN_N) 

Vfi / 

Vfi y 

i AbsoluteValue -Y '^y [AbsoluteValue^ .y) 

' AbsoluteValue -initialize', \lX • Input \ AbsoluteValue -.output \ Output \ end-cycle — >X 
Figure 7: Circus model of the implementation of the chart in Figure [2] 



If the state has a sequential decomposition, its status is modelled by two variables in D_WorkJX. 
The variable is_active_S is as described above. The variable is_S records a number that identifies which 
substate is active at the time, its value is zero if there are no active substates. If a state is a child of a state 
with a sequential decomposition, no variable of the form is^activeJS is created, as the information about 
its status is already recorded in the variable is_P, where P is the name of its parent state. 

In our example, we have only states with sequential decompositions. The status of the chart is 
recorded by is_active_cl_AbsoluteValue and is_cl_AbsoluteValue. There is no need for vari- 
ables that record the status of P and M, as this information can be obtained from is_cl_AbsoluteValue. 

We model the implementation as a series of schemas and a single process. Figure [7] gives a partial 
view of the model of the implementation of our example. Schemas model the records in the implemen- 
tation. For instance, D_Work_AbsoluteValue is modelled by the schema DJWorkJKbsoluteValue. 

For each of the relevant C function in the implementation, we define a Circus action that models it. 
In Figure|7} we present the Circus action that models the function AbsoluteValue_output. The main 
action of the process is fixed and consists of calling the initialisation action (AbsoluteValue initialize for 
our example), and recursively reading the inputs (with the action Input), producing the outputs (with the 
action AbsoluteValue -output), offering the outputs (with the action Output), and signalling the end of the 
"time-step" by synchronising on enducycle. The actions Input and Output abstract as communications 
the shared variables used to implement inputs and outputs. 

In the modelling of the functions, we map C constructs to similar Circus constructs. Loops are 



A. Miyazawa, A. Cavalcanti 



73 



Proof obligation: retrieve relation is 
a total surjective function from the 
concrete state to the abstract state 



Proof obligation: rewriting guards 
in conditionals and expressions 



Data 




Normalisation 




Parallelism 




Simplification 




Structuring 


refinement 


► 


► 


elimination 


► 


► 



Fully automated 



Figure 8: Overview of the refinement strategy 



modelled using recursion. In general, the translation of implementation constructs is direct, except for 
the assignment to a variable of a structure. Since we cannot write b.f := v (as a translation of b.f = 
v), for a variable b of type binding, we define Circus actions that specify the assignment of a binding 
to the variable, as the action AbsoluteValue_DWork_is_cl^AbsoluteValue in Figure [7] This action takes 
one parameter x of type N, and assigns a binding of the schema DJWork^AbsoluteValue to the state 
component AbsoluteValue_DWork. The binding is formed by associating each component of the schema 
to a value, the component is^active-d-AbsoluteValue is associated to the value of the same component, 
and is_c\_AbsoluteValue is associated to the value of the parameter. 

In the next section, we discuss a refinement strategy that supports the verification of the models of 



implementations just described with respect to the models discussed in Section 2.3 



4 Refinement Strategy 

Our refinement strategy consists of five phases: data refinement, normalisation, parallelism elimination, 
simplification, and structuring. Figure [8] illustrates the strategy; it identifies the fully automated phases 
and the proof obligations that stem from the other phases. 

In the data refinement phase, we modify the state of the chart process in order to conform to the state 
of the implementation model. The normalisation phase transforms the parallel composition of the chart 
and simulation processes into a single process whose main action initialises the state and recursively 
offers an action that encodes a step of execution of the chart. The parallelism elimination phase collapses 
the parallel actions that occur in the resulting process. This is necessary because the parallelism in the 
diagram model reflects the operational semantics of Stateflow, not a parallel design for a program. In the 
simplification phase, we simplify expressions and predicates, and move assumptions through the model 
to eliminate unreachable branches of alternations. Finally, in the structuring phase, we rewrite the main 
action to match the functions of the implementation, and therefore the actions of its model. 

The strategy proposed in this section is generic enough to be applied to a large class of charts and 
implementations. It takes advantage of restrictions on the architecture of the implementation to support 
a high degree of automation. We consider here only sequential implementations of Stateflow diagrams. 
The steps of the strategy are, however, useful in the refinement to parallel implementations as well. 

In the sequel, we describe the details of each phase. They define procedures to apply existing and 
novel Circus refinement laws whose soundness guarantees the soundness of our verification strategy. 
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ConcreteState 

AbsoluteValue_state 

AbsoluteValueJDWork.is_c\^AbsoluteValue G {0, 1,2} 



Figure 9: Restricted concrete state 

4.1 Data refinement 

In this phase, we construct a retrieve relation between the abstract state of the chart process and the con- 
crete state of the implementation model. With that, we use the Circus calculus to construct a refinement 
of the chart process, and so preserve its structure, and transform the assignments, operation schemas, 
and communications. Precisely, we follow the procedure below for constructing retrieve relations that 
are total surjective functions from concrete to abstract states. They allow us to proceed with the data 
refinement in a calculational fashion. 

The state components of the implementation model belong to one of four groups: execution spe- 
cific data, like AbsoluteValue_DWork in our example, local variables (like AbsoluteValue_B), input 
variables (like AbsoluteValue_U), and output variables (AbsoluteValue_Y). Additionally, we can 
restrict the components of the concrete state to take values only over the appropriate sets. For exam- 
ple, Figure [9] shows the state of our implementation model with one additional invariant; it requires that 
is_c\^AbsoluteValue takes values from {0, 1,2}. 

The retrieve relation maps the execution specific data to the components of SimulationData, and the 
local, input and output variables to components of Simulationlnstance . The correspondence between 
the input and output variables is trivial. It is obtained by equating the concrete variables to the abstract 
variable whose name is the same except for a prefix v_. The specification of the relation between the 
execution specific data of the concrete state and the function state_status in SimulationData is obtained 
by using a set comprehension where, for each state identifier s, we define a boolean active that determines 
its status from the concrete state. These conditions can be calculated as follows. For a chart name 
C, and each component of D_Work_C (in our example, the schema D_Work_AbsoluteValue) named 
is ^active -name (is^active-d^AbsoluteValue, for example), where name is the name of state (or chart), 
we have the following condition. 

s = name A active = (if C_DWork.is_active_name > Othen True else False) 

For instance, the condition for isuactive-c\-AbsoluteValue equates s to c^AbsoluteValue, and active to 
True or False depending on whether the value of is_active_c\_AbsoluteValue is greater than zero or not. 

For each component of the schema DJWorkJC of the form is_name, where name is the name of a 
state (or chart), we formulate a condition in the following way. For each substate X of name, we define 
the condition below. 

s = sJK A active = (if C-DWork.is_name = C^NJK then True else False) 



In our example, the condition for the state P equates s to s_P, and active to True or False depending 
on whether the value of is_c\-AbsoluteValue is AbsoluteValue_IN-P or not. All these conditions are 
composed in a disjunction as shown in the definition of the retrieve relation for our example in Figure 10 
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RetrieveFunction 

P^A bso lu te Va lue_S 
ConcreteState 

statestatus = {s : domstates; active : B • 

s = s_N A active = if AbsoluteValue_DWork.is_c\ -AbsoluteValue = 

AbsoluteValue JNJ^f thenTrueelse False V 
s = s_P A active = if AbsoluteValue— DWork.is-d^AbsoluteValue = 

AbsoluteValue -IN JP then True else False V 
s = c -AbsoluteValue A active = 

if AbsoluteValueJDWork.isuactive-cXJKbsoluteValue > Othen True else False} 
state -history = {} 
v_m = AbsoluteValue JU .u 
v_y = AbsoluteValue_B .y 



Figure 10: Total surjective functional retrieve relation 



Since our example does not contain history junctions, the implementation has no state components 
that model the state component state Jiistory of the chart process. The model of the chart establishes that 
this state component is the empty partial function, therefore we equate state Jiistory to the empty set. 

The retrieve relation in Figure [T0]is functional because each abstract state component is defined by a 
function of a component of the concrete state. Since no restriction is imposed on the concrete state for the 
applicability of the function, the relation is also total. Moreover, for every abstract state A, it is possible 
find a concrete state that is related to A by the retrieve relation because the functions are invertible. 

Using this retrieve relation, we apply the laws of simulation ||6l |T9l to obtain a Circus process 
C_P -AbsoluteValue by data refinement of P -AbsoluteValue, and to refine the process AbsoluteValue 
to a process CAbsoluteValue, as shown in Figure[TT] We define the constant ss to increase the readability 
of C_P ^AbsoluteValue. This function is defined as the characterisation of statestatus in Figure [T0| 

The main action does not change, but components of the actions that it uses are transformed. For 
example, Activate and InitState are data refined to operate over the concrete state. Figure 1 1 shows part of 
the definition of CInitState (the data refinement of the schema InitState); it shows the part of the predicate 
that defines the operation. The actions condition JP JN , Inputs, and Outputs are also data refined; the first 
has the component v_u rewritten to AbsoluteValue JJ .u, the second has the assignment transformed into 
an action that assigns a value to a component of a schema binding (as mentioned in Section [3), and the 
third has the component v_y substituted by AbsoluteValue _B .y, in accordance with the retrieve relation. 

In the next section, we describe how to collapse the parallel composition in CAbsoluteValue. 



4.2 Normalisation 

In this phase, we first collapse the parallelism between the chart and simulator processes in the process 
CAbsoluteValue, and rewrite the main action of the resulting new process to a normal form: an initiali- 
sation action, followed by a recursive action. This allows us to focus on the body of the recursion that 
characterises one step of execution. 
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process C_P^AbsoluteValue = begin 
StateflowChart 
identifier = c^AbsoluteValue 

states = { (s-P, S-P) , (s-N,S-N), (c-AbsoluteValue,C-AbsoluteValue)} 
transitions = {(f_P_JV, r_PJV), . . . , (*_6JV, T_6JV)} 
junctions = {(/5, 75), (76, 76)} 

m:S/D-b-B 

m = : dom^toto; active : B • 

5 = 5_A^ A active = if AbsoluteValue_DWork.is_cl-AbsoluteValue = AbsoluteValue_IN_N 

then True else False V 
5 = s_P A active = if AbsoluteValue_DWork.is_c\^AbsoluteValue = AbsoluteValue_IN_P 

then True else False V 
s = c^AbsoluteValue A active = AbsoluteValue_DWork.is_active_c\^AbsoluteValue} 

state ConcreteState 

CActivate == [AConcreteState; xl : >S7D | . . .] 

CInitState == [ConcreteState' \ AbsoluteValue_DWork' .is_active-c\^AbsoluteValue = False A . . .] 



condition_P_N = if '((AbsoluteValue_U .uK^O) 7^ 0) )■ 

Inputs = (read-inputs — > (i_u7x — > AbsoluteValue-U -u(x))) 
Outputs = {write -outputs — > (o_y\(AbsoluteValue_B .y) — > Skip)) 

(/ / ((All Actions A (interrupt _chart — >Skip));F) 

J juy • J □ ) ) ; X 

\ \ end-cycle — > Skip 

end 

process CAbsoluteValue = Simulator I interface U {] end-cycle [} ] C-P^AbsoluteValue 
Figure 11: Data refinement of the processes shown in Figure [4] 
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/ / (cinitState); 

I / / AllActions 

A 

jlX» /1Y ' * 



V 



V 



(interrupt ^chart — > Skip) 



□ 



/ 



; x 



J 



\ end— cycle — s-Skip 
\{AbsoluteValue_B,AbsoluteValue_DWork} \ interface U ^end-cycle\\ | {} 

(flX • Step ; X) 

Figure 12: Combined main action after merging the two processes. 



\ interft 



ace 



/ (cinitState); 

( ( ( AllActions 

A 



jlY> 



□ 



\ 



; y 



(interrupt — chart — > Skip) 



\ interface ; X 



\ end_cycle — s-Skip / 
[•••1 

V V Step ) ) 

Figure 13: Main action after the normalisation phase (We abbreviate the parallelism). 



We construct the new process by taking the state of the chart process (the simulator process is state- 
less), and combining the main actions of the chart and simulator processes in the same way the processes 



were combined, as shown in Figure 12 This is a direct application of the definition of the semantics of 
process parallelism in Circus. 

Next, we move the schema action CinitState out of the parallel composition, distribute the hiding 
over the sequential composition, and eliminate the hiding over CinitState. The external recursion in the 
first action of the parallel composition, and the recursion in the second action are then merged. This 
is possible because Step necessarily terminates in a synchronisation over the channel end-cycle, since 
this channel is in the synchronisation set, and this synchronisation stops the inner recursion, and starts a 



new cycle of the external recursion. We are left with the action in Figure 13 which calls CinitState, and 



recursively executes the parallel composition of a recursion (the recursion over Y in Figure 12 1, and the 
action Step, with the channels in interface hidden. 



4.3 Parallelism elimination 

In this phase, we eliminate the parallelism still embedded in the main action. The parallel action inside 



the recursion of Figure 12 reads an input event, reads the input variables, executes the chart, writes the 
outputs, and ends the cycle. In general, the step of execution involves a series of communications over 
channels that may or may not be in the synchronisation set. Communications over channels not in the 
synchronisation set are moved outside the parallel composition, and the others are used to select an action 
from AllActions (or trigger an interruption). We proceed as follows to evaluate the communications and 
remove the parallelism. 
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/ (cinitState); 

( input -event! ie- 
( I i_u!x — 
/ 



ilX 



\ 



\ 



AbsoluteValue-U -u{x); 
AllActionsA 

[interrupt _chart — > Skip) 



; y 



□ 



\ end— cycle — s-Skip 



/ 



V 



/ / ExecuteChart(ie) \ \ 

A 

interrupt simulator — > 
\ K interrupt _chart — s-Skip J ) 
\ write -outputs — >end-cycle — )-Skip J 



\ interfi 



ace 



J 



; x 



J 



J 



Figure 14: Main action after the communications over input-event and read-inputs are treated. 



By expanding the definition of Step in Figure 13 we have two communications one after the other. 



The first is a communication over the channel input-event that is not in the synchronisation set, and the 
second is a synchronisation over read-inputs, which is in the synchronisation set. We move the commu- 
nication outside the parallel composition, unfold the recursion over Y, and resolve the communication 
on the channel read-inputs. This produces a prefixing action identical to the body of the action Inputs in 



Figure 11 Because the communication is hidden, we eliminate it and obtain the action in Figure 14 



The actions that can be selected can be an atomic information request, as exemplified by read-inputs, 
a non-atomic information request, or a Stateflow action request. In the first case, as already shown, the 
parallelism can be removed by resolving the communication. In the case of a non-atomic request (for 
instance, a trigger action of Figure [4]), the action is composed of two communications. To eliminate the 
parallelism we resolve them; this potentially involves resolving a conditional expression that selects the 
appropriate value to communicate. A Stateflow action request consists of a communication that identifies 
the appropriate action, a series of Circus actions that encode the Stateflow action, and a synchronisation 
that indicates completion. In this case, the initial communication and the final synchronisation are treated 
as usual. The encoding of the Stateflow action contains assignments and local event broadcasts. Assign- 
ments are moved out of the parallel composition, and broadcasts produce a recursive execution of the 
chart, which can be treated using the same strategy. 

The strategy for eliminating parallelism can be seen as a two level strategy. The first level is guided 
by the structure of the simulator process, which potentially leads to the execution of an action of the 
chart process, and the second level is guided by a chart process action that has been executed. Since the 
simulator process is the same for all charts, we explore its structure to define the refinement strategy. The 
same is not true for the chart process, but due to the simple structure of the actions in the chart process, 
we can explore the limited patterns that occur. 



At the end, we obtain a main action whose structure is as shown in Figure 16 There, we have already 
simplified expressions, which is the objective of the next phase. 
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AllActions; Y 
flYm | □ 

end-cycle — > Skip 
[•••1 

/ status\{states(c^AbsoluteValue) .identifier)! active — > 
/ if active = True — > 

ExecuteActiveChart{states(c^AbsoluteValue) , ie) ; 
write_outputs — > end— cycle — > Skip 
active = False — > 

ExecuteInactiveChart(states{c^AbsoluteValue) , ie) 
write-outputs — > end-cycle — > Skip 

V V Vfi 



/ 



\ interface 



I J 



Figure 15: Parallel action of the main action in Figure 14 after further refinement steps. 



4.4 Simplification 

In the simplification phase, we transform expressions and eliminate unreachable branches of conditional 
statements. The simplification of expressions takes advantage of the constants that model the structure 
of the chart, as well as state invariants. For instance, Figure [15] contains an expression that appears 
frequently in communication resolutions: states(c^AbsoluteValue). identifier. It evaluates to the identifier 
of the state whose identifier is c^AbsoluteValue, but this is exactly c^AbsoluteValue, thus we simplify it. 



After these simplifications are carried, we obtain a main action as in Figure 16 The last branch of the 
second conditional has the guard: AbsoluteValue-DWork.is_c\^AbsoluteValue / AbsoluteValue^IN '_JV '. 
Since AbsoluteValue_IN_N=2, the invariant of the concrete state implies that 

AbsoluteValueJDWork.is_c\^AbsoluteValue = 1 V AbsoluteValueJDWork.is_c\^AbsoluteValue = 

Therefore, since AbsoluteValue_IN '_P is a constant defined as 1, we replace the above guard with 

AbsoluteValue_DWork.is_c\^AbsoluteValue = AbsoluteValue_IN_P V 
AbsoluteValueJDWork.is_c\^AbsoluteValue = 

This guard is then broken in two, and a new branch is added to the conditional statement. We proceed 
in this way for every guard defined by a disjunction that checks the status of a state. This simplification 
is applied whenever the status of a state in a sequential decomposition is checked because our model 
always includes a branch whose guard is an inequality. It is necessary because, while our model contains 
only binary conditionals, the implementations may have conditionals with more than two branches. 

We traverse the resulting action and for each conditional statement found, we attempt to simplify 
the guard. If we can simplify a guard to false, we eliminate the branch. If the guard is true, we reduce 
the whole conditional to the action it guards; this is correct, because all our conditionals are of the form 
if b — > . . . [] -i b — > . . . fi. If a conditional statement cannot be simplified, it should match a conditional 



statement in the model of the implementation. For example, the first conditional statement in Figure 16 
corresponds to the first conditional statement of the action AbsoluteValue_output in Figure [7] 
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» CInitState; llX • input^eventlie — >i-ii!x — > Absolut eValued ' _u{x); 

/ if ss{c_AbsoluteValue) = False V . . . 

\ss{c -AbsoluteValue) = True Y 

f \fAbsoluteValuedWork.is_c\_AbsoluteValue — AbsoluteValue JNd > 

( if '{{AbsoluteValueJJ. u> ^0) ^ 0) > 

( HAbsoluteValueJ)Work.is_c\dbsoluteValue — AbsoluteValue JN d- 
Deactivated; Deactivated?; Activated; 

ii(AbsoluteValue_U .u<^0) ^ 0) > . . . 

{{{AbsoluteValue d .u< e /§) ^ 0)) > . . 

fi 

\\AbsoluteValuedWork.is_cldbsoluteValue 7^ AbsoluteValue JNd - 
Deactivated; Activated; 

if '{{AbsoluteValueJJ .u< :S /0) 7^ 0) > . . . 

(((AfooZMfeVaZMe_C/.M<. c ,/0) ^ 0)) > . . 



V 



/ 

► AbsoluteValued_y{— AbsoluteValue. 



{{(AbsoluteValueJJ .u>^0) ^ 0)) 

( if '{{AbsoluteValueJJ. uK^O) ^ 0) » 

/ ifAfoo/M?eVa/i<e^Wor&./s_cl^Z?so/MfeVaZMe — AbsoluteValue JN d - 



\\AbsoluteValuedWork.is_cldbsoluteValue ^= AbsoluteValue JNd- 



U.u); 
\ 

\ 



X 



V fl 



V fl 



(((AfeoZwfeVii/we-J/.w^O) 7^ 0)) 



\\AbsoluteValuedWork.is_cldbsoluteValue 7^ AbsoluteValueJN '_JV ^ 

/ if((A/7soZ«feyaZMe_f/.M<, c /0) 7^0) )■ 

if AbsoluteValued)Work.is-c\_AbsoluteValue = AbsoluteValueJN d - 
[jAfcsoZMfeyaZMe^Wor^./Lcl^l/jioZMfeV&ZMe 7^ AbsoluteValueJN d - 



V fl 



V fl 



{{{AbsoluteValueJJ .u<^0) 7^ 0)) • 



Figure 16: Partially simplified main action of process AbsoluteValue. 



The fourth conditional statement in Figure 16 is an example of a statement that can be simplified. The 
guard of the first branch is AbsoluteValue jyWork.is^cXJVbsoluteValue = AbsoluteValue JNd, but this 
is inside a branch whose guard is AbsoluteValue JDWork.is_cl^AbsoluteValue = AbsoluteValue JN JN , 
and since is_c\JVbsoluteValue cannot have both values (and no statement modifies this component be- 
tween the two branches), the first guard is false, and that branch can be eliminated. In this way, we put the 
model of the chart in the same shape as the model of the implementation, and once this is achieved, the 
structuring phase takes place. Formalisation of this strategy using refinement requires a law to introduce 
assumptions based on the guards of the conditional, laws to distribute and use assumptions, and finally 
a law to remove an assumption when it is no longer needed. These are standard laws that are valid in 
Circus as shown in |[T9l . 
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4.5 Structuring 

The structuring phase identifies each component of the main action that corresponds to an auxiliary 
action in the model of the implementation. It introduces this extra action in the process CAbsoluteValue, 
and uses the copy rule to replace the component of its main action by a call to it. The rationale behind 
this phase is to match the main action to that of the model of the implementation. 

For instance, we compare the action AbsoluteValue_output in the model of the implementation to the 
subactions of the main action obtained from the previous phase. We identify a subaction that is a match, 
introduce its definition, and substitute the name AbsoluteValue_output in the main action. The result of 
all this should be exactly the model of the implementation (as shown in Figure [7] for our example). If 
this is not the case, the verification has failed: either the program is wrong, or it does not conform to the 
architectural pattern that we can handle. 

The detailed application of this strategy to our example can be found in lTT4ll . 

5 Conclusion 

We have proposed a refinement-based verification strategy for implementations of Stateflow charts. This 
strategy is guided by the structure of the models of Stateflow charts described in |[T6l . We have also 
discussed how such a strategy can take advantage of the architecture imposed on generated code. 

We have provided a procedure for obtaining retrieve relations that support the data refinement of the 
specification in a calculational style, thus rendering the data refinement phase also suitable for automa- 
tion. In the case of the normalisation and parallelism elimination phases, the possibility of automation 
stems from the fixed structure of our models. The simplification phase can be semi-automated because 
the main action consists of a number of nested if-statements, and assumptions generated by the guards of 
the conditional statements (among others) can be moved into the associated action, potentially falsifying 
some of the conditions in an internal conditional statement. Finally, the structuring phase can be guided 
by matching actions from the model of the implementation to subactions of the action being refined. 

The refinement strategy for Simulink presented in [5] consists of four steps that systematically col- 
lapse the massive parallelism of the diagram specification to match the processes of the implementation 
model, prove that each of the procedures in the implementation refine the action that specifies it in the 
corresponding process, and finally, prove that the parallel programs refine the process that specifies the 
system. The main actions of component processes are put in a normal form where they are defined as 
the iterative execution of a step that consists of reading the inputs in interleaving, calculating the outputs 
and updating the state, writing the outputs in interleaving, and synchronising on the channel end_cycle. 

Our strategy has a similar nature, however, it is worth mentioning some important differences. Our 
models of Stateflow charts owe their parallelism to the separation between the structure of the model 
and the operational semantics of the simulator, not to any implicit or explicit parallelism in the chart. 
Therefore, while in [5 ] collapsing the parallelism is guided by the implementation model, in our strategy 
it is performed until there are no parallel actions left. The beginning of our parallelism elimination 
phase is similar to the process of putting the main action in a normal form in the strategy for Simulink 
diagrams. The equivalent step in our model is, however, not as linear as in lH. The decision to end 
the cycle comes from the action inherited from the simulator process. Nevertheless, by the end of the 
parallelism elimination phase, we have a process whose main action is in the normal form of Q. This 
suggests that not only our models can be integrated to the models of Simulink diagrams, but also that our 
strategy can be used to put a Stateflow block in the normal form prescribed in Q. This will support the 
integrated use of these verification techniques for Simulink diagrams involving Stateflow blocks. 
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There are several approaches to the formal analysis of Stateflow diagrams. These works aim at the 
analysis of diagrams, not of their implementations. Operational and denotational semantics are proposed 
in iTTTIl and IfTOl : these support static analysis, interpretation, and compilation of Stateflow charts. Trans- 
lations of Stateflow into notations that support model checking are presented in [ 1 ], [26], 621 . and 0. 
Verification in these approaches is based on temporal logics and bisimulation, rather than refinement, 
thus verification of implementations is not the objective. An approach based on Z to verify that the chart 
satisfies a set of requirements of the system being modelled is presented in 68l . However, it places 
strong restrictions on the Stateflow notation. 

Olderog |[T8l integrates three views of a system (trace specification, process algebra and Petri nets) by 
formalising a relation between them. While this approach ends in a graphical notation, namely Petri nets, 
we take the opposite direction: from a graphical notation to a program. In 6j, the refinement calculus is 
adapted to Simulink diagrams, but they do not cover Stateflow charts, and their goal is not the verification 
of implementations, but the development of diagrams from contracts. In EOl , a semantics for ii -Charts 
is constructed in Z, and a notion of refinement of ii -Charts is derived from the existing Z refinement 
calculus. This approach is similar to that presented in |fT6l , where we define a semantics of Stateflow 
charts in Circus, thus allowing the Circus refinement calculus to be applied, but it differs in the sense that 
we focus in a industrial non-formal notation, while the ii -Charts notation is a simplification of Statecharts 
mainly used in academia. Moreover, our approach goes beyond the application of the refinement calculus 
to Stateflow charts; it addresses the problem of automation of the refinement process. 

As far as we know, this is the first work to address the issue of verification of implementations of 
Stateflow charts. Moreover, as explained in detail lfl3Tl . our models of Stateflow charts used as the base 
for the verification eliminate many of the restrictions imposed in other formalisations. 

Given the generality of our refinement strategy, we believe it scales well to modified implementa- 
tions. In particular, an implementation that does not modify the use of the variable AbsoluteValue_DWork 
should still be amenable to the specialisation of the refinement strategy discussed in Section 4.1 More- 
over, our strategy can be used as a preliminary phase in the verification of parallel implementations, as 
all the parallelism eliminated by the strategy derives from the structure of the model. 

As future work, we will address the issue of verification of parallel implementations of Stateflow 
charts. Parallel implementations are not common, and as far as we know there are no code generators 
that produce parallel implementations. We will extend the current strategy to allow the verification to be 
carried out after the introduction of parallelism in the implementation using fixed design patterns. 
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